kermit.columbia.edu/kermit.columbia.edu.tar/kermit.columbia.edu/newsgroups/misc.19950929-19951130/[e-mail]_Wed Oct 4 01:31:11 1995.msg

Internet Message Format | 1995-12-25 | 7KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA24122
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Thu, 5 Oct 1995 04:53:03 -0400
Received: by apakabar.cc.columbia.edu id AA08934
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Thu, 5 Oct 1995 04:53:00 -0400
Path: news.columbia.edu!panix!tinman.dev.prodigy.com!prodigy.com!newsjunkie.ans.net!howland.reston.ans.net!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: [e-mail] (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: ?Warning:unknown hardware for port
Message-Id: <[e-mail]>
Date: 4 Oct 95 07:31:11 MDT
References: <445vuc$[e-mail]> <[e-mail]> <[e-mail]>
Organization: Utah State University
Lines: 112
Apparently-To: [e-mail]

In article <[e-mail]>, [e-mail] writes:
> In article <[e-mail]>, [e-mail] (Joe Doupnik) writes:
>> In article <445vuc$[e-mail]>, [e-mail] (Robert Ong) writes:
>
>>> In the Windows environment, we load WGTCPIP & TELAPI and the connection
>>> works fine. One problem that our users find very unnerving is the message
>>>
>>>     ?Warning: unknown hardware for port: Using the Bios as BIOS1.
>>>
>
> [. . .]
>> port/IRQ at the same time. Do you have a real-mode TSR grabbing the
>> port? SLIP_PPP will do so, so will some mouse drivers. I am no expert
>> on Win 3.1x serial port mumbo jumbo in system.ini, but if yours is slightly
>> tangled then a trip to the Windows Resource Kit is a good suggestion.
>>         Joe D.
>
> In one sense the following info doesn't help at all; in another sense it
> may be some help to know this is a hard-to-track-down-problem that
> exists in very simple/standard setups.
>
> I routinely run Kermit on port 2 in one of several DOS VM's
> under Windows 3.1.  I've seen the "unknown hardware" msg sporadically
> and unrepeatably, most recently about 60 seconds ago.  All my attempts
> to track this down have failed.  Kermit is the only comm software I
> run.  The dos mouse driver is always loaded before windows and is
> configured for COM1.  When so configured, it does not touch
> COM2 (I tested this using a protected-mode utility which protects
> the i/o port addresses and watches for attempts to access them).
>
> I've seen the problem with two different I/O boards, everything standard
> about them, standard irq's, standard port addresses, except that my
> current card has 2 16550's instead of 2 8250's.
>
> There's nothing "tangled" about my serial port set up.  The .ini
> entries are just as they came off the windows installation disks.
>
> My resolution of the problem is always the same--I exit Kermit and
> reinvoke it.  Problem is always gone, and I may not see it again
> for days.
>
> No TCP/IP drivers or network drivers of any sort are loaded.  This
> is a straight serial port to modem connection on my standard, clone
> home machine.
>
> The only memory-resident software loaded is standard DOS/WINDOWS
> stuff:  HIMEM, EMM386, etc.
>
> My latest example of this symptom is typical in its nonrepeatability:
>
> I turned on the machine, intended to use Kermit for a couple of minutes,
> and did so from DOS without bothering with windows.  I was then online
> longer than expected and decided to exit Kermit, start windows, then
> reinvoke Kermit (I can always do this without losing my connection).
>
> I'd just read msgs in this news group.  I exited Kermit, started Windows,
> created 3 dos vm's, entered the first created and invoked Kermit.
> I got the unknown-hardware error.  I exited Kermit, but not the DOS VM,
> reinvoked kermit, and everything was back to normal--I was still on line.
>
> I can hear some readers thinking "Aha! I know what happened to him."
> Yes, if this sort of thing routinely produced the error I could
> guess what's causing the error, too.  But my point is that I don't
> ordinarily get the error in that situation.  (And, I sometimes get
> it when I've invoked Kermit only under windows, not from straight dos.)
>
>
> To test whether I could repeat the error tonight, I did this:
> I logged off the remote system, turned off my system, and repeated
> the earlier series of events.  This time the error did not appear.
> (FWIW: I have enough physical RAM that I don't need virtual memory;
> so the problem isn't being caused by some specific sequence of page
> faults that may vary when the user thinks nothing has changed.)
>
> This has been my consistent experience with this problem over a period
> of a couple of years.  I simply cannot repeat the error reliabily,
> and I've had lots of experience tracking down bugs.
>
> I've seen this same thing on systems at work, where the environment
> is more complex than on my home machine (network connections are
> involved at work).
>
> None of this puts the fault at Kermit's feet.  I suspect there's
> something flaky going on with Windows.  Kermit is the best thing
> I've run under Windows.  I especially like it's ability to do fast
> background transfers while I'm working in other DOS VM's.
> Kermit is very well designed software.
>
> Regards,
> Larry Mayhew
> [e-mail]
----------
    There is another item in this discussion which can cause the effect.
Your mouse is on COM1. If the Kermit startup script(s) has(ve) a command
which causes a serial port to be opened for inspection, such as SET SPEED
or similar, then it could well be the default port at that time is COM1
rather than the port you will use later. Moving the mouse to COM2 may be
an easy permanent cure for use with Kermit and other programs, else edit
the script(s) to set the desired serial port before other commands get a
chance to probe the port.
    And yet more. Windows itself. Kermit looks at the status bits of
the presumed UART to see if they are rational for a UART. If Windows has
those messed up then we get the message. If Windows provides an incorrect
port address, the \03f8 thing, then clearly matters will fail too. There
is a final test for interrupts, the IRQ value, and it's there that matters
are sticky. If Windows messes up simple interrupt handling for the serial
port MSK will declare the port invalid. Handing of the interrupt controller
chip by Windows (it is simulated to apps such as Kermit) has improved over
time in Windows so an older driver might produce flakey results. That's the
device=*vpicd line in system.ini, file windows\system\vpicda.386.
    Enough grasping at straws this morning.
    Joe D.